fix(ci): revive the pipeline — Deno purge blanked the base image; move to Bun - #107

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- .gitlab-ci.yml ---'
cat -n .gitlab-ci.yml | sed -n '1,35p'
printf '%s\n' '--- Bun version references ---'
rg -n -S 'BUN_VERSION|oven/bun|1\.3\.14|bun --version|bun version' .gitlab-ci.yml . 2>/dev/null | head -120

Repository: hyperpolymath/ubicity

Length of output: 1177

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- relevant files ---'
git ls-files .gitlab-ci.yml package.json bun.lock bun.lockb package-lock.json yarn.lock pnpm-lock.yaml
printf '%s\n' '--- CI lint commands ---'
cat -n .gitlab-ci.yml | sed -n '25,42p'
printf '%s\n' '--- package manifest ---'
cat -n package.json
printf '%s\n' '--- lockfile tool entries ---'
if [ -f bun.lock ]; then
  rg -n '"(eslint|prettier|`@typescript-eslint`|eslint-config|eslint-plugin|prettier-plugin)[^"]*"' bun.lock | head -80 || true
fi
if [ -f bun.lockb ]; then
  printf '%s\n' 'bun.lockb exists'
fi

Repository: hyperpolymath/ubicity

Length of output: 924

🌐 Web query:

Bun official documentation bunx package not installed auto-install latest version package resolution

💡 Result:

The bunx command is a built-in alias for bun x and is automatically installed when you install Bun; there is no separate package to install for bunx [1][2][3]. When you execute a command using bunx, it follows this resolution logic: 1. Local Check: bunx first searches for the package in your project's local node_modules/.bin directory [1][4][3]. 2. Auto-install Fallback: If the package is not found locally, bunx automatically downloads the latest version of the specified package from the npm registry [1][5]. 3. Caching: Once downloaded, the package is stored in Bun's global cache, ensuring that subsequent executions are significantly faster [1][3][6]. If you need to specify a package when the binary name differs from the package name, or if you wish to force the use of a specific version or package rather than relying on the default resolution, you can use the --package (or -p) flag [1][3][7]. For example: bunx -p This approach allows you to explicitly control the package resolution while benefiting from bunx's automatic caching and fast execution [3][7].

Citations:

• 1: https://bun.com/docs/pm/bunx
• 2: https://bun.sh/docs/pm/bunx
• 3: https://oven-sh-bun.mintlify.app/pm/bunx
• 4: https://github.com/oven-sh/bun/blob/main/docs/pm/bunx.mdx
• 5: https://bun.com/docs/runtime/auto-install
• 6: https://blog.openreplay.com/bunx-when-to-use/
• 7: Support for bunx --package to force download from npm instead of node_modules/.bin oven-sh/bun#25026

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- CI relevant sections ---'
sed -n '150,215p' .gitlab-ci.yml
printf '%s\n' '--- candidate visualisation files ---'
fd -i 'visual|map|ubicity' . --type f | head -80
printf '%s\n' '--- quickVisualize references ---'
rg -n -C 4 'quickVisualize|ubicity-map\.html|artifacts:|pages' --glob '!node_modules/**' --glob '!dist/**' .

Repository: hyperpolymath/ubicity

Length of output: 9759

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- src/visualize.js outline ---'
ast-grep outline src/visualize.js
printf '%s\n' '--- src/visualize.js ---'
cat -n src/visualize.js
printf '%s\n' '--- src/index.js relevant section ---'
sed -n '1,105p' src/index.js
printf '%s\n' '--- storage constructor and visualisation methods ---'
sed -n '1,125p' src/storage.js

Repository: hyperpolymath/ubicity

Length of output: 25821

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- UrbanKnowledgeMapper constructor and storage wiring ---'
ast-grep run --pattern 'class UrbanKnowledgeMapper { $$$ }' --lang javascript src/mapper.js --debug-query=pattern 2>/dev/null || true
rg -n -C 8 'class UrbanKnowledgeMapper|constructor\(|new ExperienceStorage|storageDir' src/mapper.js

Repository: hyperpolymath/ubicity

Length of output: 15301

🌐 Web query:

Bun documentation unhandled promise rejection process exit code async IIFE unhandled rejection

💡 Result:

In Bun, the behavior regarding unhandled promise rejections—including those occurring within asynchronous functions or IIFEs—has evolved to prioritize reliability and standard-compliant exit codes [1][2]. Core Behavior and Exit Codes When a promise rejection remains unhandled at the end of the application's lifecycle, Bun reports the error and typically sets the process exit code to 1 [1]. This behavior ensures that scripts do not exit silently with a success code (0) when an error has occurred [1]. Unhandled Rejections in Async IIFEs Historically, there were scenarios where unhandled rejections inside async IIFEs or functions would not propagate correctly, leading to silent failures [3][1]. Recent updates have addressed these issues, ensuring that unhandled rejections are properly tracked and reported [1][4]. If you encounter a situation where an async IIFE appears to fail silently, ensure you are using an up-to-date version of Bun, as improvements to promise/async handling for IIFEs have been implemented to fix these edge cases [4]. Process Handling and Configuration - Process Listeners: You can hook into unhandled rejections using process.on('unhandledRejection', (reason, promise) => { ... }) [5][6]. - --unhandled-rejections Flag: Bun supports the --unhandled-rejections flag, similar to Node.js [7]. Using --unhandled-rejections=throw forces rejections to escalate as uncaught exceptions if no handler is provided, which is a standard approach for stricter error management [8][5][7]. - Event Loop: Bun monitors for unhandled rejections at the tail of job queues (such as job_queue::run_jobs) [5]. It ensures that if an unhandledRejection handler is present, it is executed, and if not, the rejection is handled based on the configured mode (defaulting to reporting the error) [5][9]. Special Contexts - Web Workers: Unhandled rejections in node:worker_threads workers are designed to report an exit code of 1, matching Node.js semantics [10]. - Bun Test: When running tests, Bun tracks unhandled rejections that occur between tests or during file loading; if any occur, the test process exits with a non-zero code [11]. If you are experiencing unexpected behavior, it is recommended to explicitly register an unhandledRejection listener if you need custom logic or logging, and verify your Bun version, as internal mechanisms for rejection tracking are frequently refined [5][9].

Citations:

• 1: Report unhandled promise rejection on exit oven-sh/bun#1734
• 2: Emit unhandledRejection at the end of the tick that created it oven-sh/bun#33354
• 3: Unhandled Rejections within async functions oven-sh/bun#970
• 4: Silent failure when running await Bun.file("doesnotexist").json(); (and other file functions on a non existent file) when in IIFE/CJS mode of execution oven-sh/bun#24762
• 5: https://docs.rs/bun_runtime/latest/src/bun_runtime/uncaught.rs.html
• 6: https://bun.com/reference/node/process
• 7: Support --unhandled-rejections flag and rejectionHandled event oven-sh/bun#19874
• 8: process: match Node exit code semantics; fix node:events captureRejections oven-sh/bun#32814
• 9: Drain the microtask checkpoint after unhandledRejection handlers run oven-sh/bun#33356
• 10: worker_threads: exit code 1 when a Worker dies from an unhandled rejection oven-sh/bun#34193
• 11: https://bun.com/docs/test/runtime-behavior

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- CI base definition and runtime pins ---'
sed -n '1,45p' .gitlab-ci.yml
printf '%s\n' '--- package/runtime metadata ---'
fd -H -i 'package.json|bun.lock|bun.lockb|Dockerfile|.*bun.*' . --type f | head -60
for f in package.json bun.lock bun.lockb Dockerfile; do
  if [ -f "$f" ]; then
    printf '%s\n' "--- $f ---"
    sed -n '1,80p' "$f"
  fi
done

Repository: hyperpolymath/ubicity

Length of output: 4983

🌐 Web query:

site:bun.com/docs unhandled promise rejection exit code Bun default

💡 Result:

In Bun, the default behavior for an unhandled promise rejection in a standard script execution is to print a source-code preview, error message, and stack trace to the console, but it does not automatically exit the process with a non-zero code [1][2]. However, the behavior differs in specific contexts: 1. Bun Test Runner: When running tests with bun test, the test runner explicitly tracks unhandled promise rejections. If one occurs, it reports an "Unhandled error," stops the execution of that test file, and exits the process with a non-zero exit code (typically 1) [3]. 2. Custom Handling: You can ensure a script exits on an unhandled promise rejection by manually listening for the event and calling process.exit(1) [3]: process.on("unhandledRejection", (reason, promise) => { console.error("Unhandled Rejection at:", promise, "reason:", reason); process.exit(1); }); If you are working with Bun's shell integration (bun:shell), the default behavior for commands that return a non-zero exit code is to throw a ShellError, though this can be disabled using .nothrow() [4].

Citations:

• 1: https://bun.com/docs/runtime/debugger
• 2: https://bun.com/docs/runtime/debugger.md
• 3: https://bun.com/docs/test/runtime-behavior
• 4: https://bun.com/docs/runtime/shell

• .gitlab-ci.yml#L84-L84 (this comment)
• .gitlab-ci.yml#L84-L84